ETSITS102 142V1.1.1 



(2003-05) 



Technical Specification 



Services and Protocols for Advanced Networks (SPAN); 

MTP/SCCP/SSCOP and SIGTRAN (Message of SS7 over IP); 

Message transfer part 3 User Adaptation layer (M3UA) 

[Endorsement of RFC 3332 (2002), modified] 




ETSI TS 102 142 VI. 1.1 (2003-05) 



Reference 



DTS/SPAN-1 30263 
Keywords 



M3UA, MTP, SCCP, SIGTRAN, SS7, 
endorsement 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, send your comment to: 
editor(a)etsi.orq 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2003. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade IVlarks of ETSI registered for the benefit of its IVIembers. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



ETSI TS 102 142 VI. 1.1 (2003-05) 



Contents 



Intellectual Property Rights 4 

Foreword 4 

Endorsement notice 4 

Introduction 4 

1 Scope 5 

2 References 5 

3 Definitions and abbreviations 5 

3.1 Definitions 5 

3.2 Abbreviations 6 

4 General considerations applicable to transport of Signalling System No. 7 over IP 6 

4.1 Transport protocol 6 

4.2 SCTP considerations 6 

4.3 National options 6 

4.4 Application Server mode 6 

4.5 Application Server state handling 6 

4.6 Dynamic registration 7 

4.7 Message distribution to the Application Server 7 

4.8 Receipt of unrecognized messages 7 

5 Considerations applicable to M3UA 7 

5.1 National options 7 

5.2 Dynamic registration 7 

5.3 Message distribution to the Application Server 7 

5.4 M3UA procedures 7 

6 Modifications to RFC 3332 7 

History 11 



£75/ 



ETSI TS 102 142 VI. 1.1 (2003-05) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

All published ETSI deliverables shall include information which directs the reader to the above source of information. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for 
Advanced Networks (SPAN). 



Endorsement notice 



The Elements of the Internet Engineering Task Force Request for Comments RFC 3332 [1] apply, with the following 
modifications. 



Introduction 



The present document records the changes to the Internet Engineering Task Force (IETF) RFC 3332 [1]. This RFC 
specifies an Internet standard track protocol for the transport of Signalling Systems No. 7 (SS7) information over IP 
using the Stream Control Transmission Protocol. 
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Scope 



The present document specifies the requirements for the MTP3 User Adaptation layer (M3UA), when used in 
conjunction with the Stream Control Transmission Protocol (SCTP) for the transport of the Signalling System No. 7 
Message Transport Part 3 (MTP3) information over the Internet Protocol (IP). The document endorses and constrains 
where relevant the SIGTRAN (IETF) RFC 3332 [1] of M3UA. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] IETF RFC 3332 (2002): "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User 

Adaptation Layer (M3UA)", G. Sidebottom, K. Morneault, J. Pastor-Balbas. 

[2] ETSI TS 102 144: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP 

and SIGTRAN; SCTP [Endorsement of RFC 2960 and RFC 3309 , modified]". 

[3] ETSI EN 300 008-1: "Integrated Services Digital Network (ISDN); Signalling System No.7; 

Message Transfer Part (MTP) to support international interconnection; Part 1 : Protocol 
specification [ITU-T Recommendations Q.701, Q.702, Q.703, Q.704, Q.705, Q.706, Q.707 and 
Q.708 modified]". 

[4] ITU-T Recommendation Q.704: "Specifications of Signalling System No. 7, Message Transfer 

Part, Signalling network functions and messages". 

[5] ETSI EG 201 693: "Integrated Services Digital Network (ISDN); Signalhng System No.7; Master 

list of codepoints". 

[6] ETSI TS 102 141: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP 

and SIGTRAN (Transport of SS7 over IP); Message transfer part 2 User Adaptation layer (M2UA) 
[Endorsement of RFC 3331 (2002), modified]". 

[7] ETSI TS 102 143: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP 

and SIGTRAN (Transport of SS7 over IP); Signalling connection control part User Adaptation 
layer (SUA) [Endorsement of SIGTRAN-SUA-14 (December 2002), modified]". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 
example 1: text used to clarify abstract rules by applying them literally 
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3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

ASP AS Process 

BEAT heartBEAT 

BEAT Ack heartBEAT Acknowledgement 

DAUD Destination state AUDit 

DRST Destination ReSTricted 

DUNA Destination UNAvailable 

DUPU Destination User Part Unavailable 

lANA Internet Assigned Numbers Authority 

IETF Internet Engineering Task Force 

IP Internet Protocol 

RFC Request For Comment 

SCTP Stream Control Transmission Protocol 

SG Signalling Gateway 

SGP SG Process 

SS7 Signalling System Number 7 

TCP Transmission Control Protocol 



4 General considerations applicable to transport of 

Signalling System No. 7 over IP 

The elements of SIGTRAN adaptation layers apply with the following exceptions and restrictions. The considerations 
in this clause are common to TS 102 141 [6], the present document and TS 102 143 [7]. 



4.1 Transport protocol 



The protocol underlying the adaptation layer for transport of SS No.7 signalling information in IP networks shall be 
SCTP. 

4.2 SCTP considerations 

The SCTP used shall conform to TS 102 144 [2]. 

The SCTP payload protocol identifier for messages pertaining to an adaptation layer shall be the one assigned by lANA 
for that layer. Adaptation layer messages received with neither the lANA payload protocol identifier nor payload 
protocol identifier equal to shall be silently discarded. 

Unordered user messages shall not be used. 

4.3 National options 

No national options excluded by ETSI standards shall apply to the present document. 

4.4 Application Server mode 

The Broadcast mode shall not be used. 

4.5 Application Server state handling 

If multiple Application Server Processes (ASPs) are used within the AS, the AS shall be considered active when the 
first ASP becomes active, and shall remain active until the last ASP becomes inactive. 
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4.6 Dynamic registration 

Dynamic registration shall not be used for configuration management. The configuration of the system shall be 
modified only by the management system, and not by the protocol itself. 

4.7 IVIessage distribution to the Application Server 

The key to enable messages to be distributed to the appropriate AS shall have a granularity no smaller than is allowed 
by the network management messages appropriate to that layer. 

4.8 Receipt of unrecognized messages 

If a message with an unrecognized message class is received, a Management Error message shall be returned with Error 
Code "Unsupported Message Class". 



5 Considerations applicable to M3UA 

5.1 National options 

No national options excluded by EN 300 008-1 [3] shall apply to the present document. 

5.2 Dynamic registration 

Dynamic registration of Routing Keys shall not be used for configuration management. The configuration of the system 
shall be modified only by the management system, and not by the protocol itself. 

5.3 Message distribution to the Application Server 

The Routing Key to enable messages to be distributed to the appropriate AS shall have a granularity no smaller than 
Point Code. 

5.4 M3UA procedures 

The M3UA procedures shall be as defined in RFC 3332 [1] augmented by ITU-T Recommendation Q.704 [4] as 
modified by EN 300 008-1 [3], except where otherwise defined below. 

6 Modifications to RFC 3332 

Modifications to RFC 3332 [1] are listed according to the sections and subsections of RFC 3332 [1]. 

Subsection 1.3.1 Protocol Architecture 

SCTP shall be used as the transport protocol for M3UA. TCP shall not be used as the transport protocol for M3UA. 

Subsection 1.3.2.1 Support for the Transport of MTP3-User Messages 

The maximum signalling information field size shall be 272 octets. 

Subsection 1.3.2.3 Interworking with MTP3 Network Management Functions 

M3UA at the ASP shall be enabled to initiate audit of availability of remote SS7 destinations. Restricted or congested 
states should not be audited. 
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M3UA at the ASP shall be enabled to indicate to SG that the M3UA layer itself or the ASP or the ASP's host is 
congested. 

Subsection 1.4.1 Signalling Point Code Representation 

M3UA shall not allow a single point code to represent both the SG and an application server. Alias point codes are not 
required. Signalling links between mated SGs are outside the scope of this specification. 

Subsection 1.4.2.1 Overview 

An ASP can belong to one or more application server. 
Subsection 1.4.2.4 Message Distribution at the ASP 

The behaviour if no active ASP is available is a nodal function. 

The default treatment if no matching routing key entry is found for incoming SS7 message is implementation 
dependent, but layer management shall be informed if the received message is discarded. 

Subsection 1.4.6 Congestion Management 

How M3UA layer is informed of local and IP network congestion is implementation dependent. However, it is 
mandatory that the M3UA layer is informed. 

When a SG determines that the transport of SS7 messages to a signalling point is encountering congestion, the SG shall 
trigger SS7 MTP3 TFC management messages to originating SS7 nodes, per the congestion procedures of 
EN 300 008-1 [3] and ITU-T Recommendation Q.704 [4]. 

Triggering of SS7 MTP3 management messages from a SG is mandatory. The means of doing this is implementation 
dependent. 

The M3UA layer at an ASP shall indicate local congestion to an M3UA peer via an implementation dependent method. 

When the SG receives an SCON from an ASP and determines that a SP is encountering congestion, it shall trigger SS7 
MTP3 TFC messages to concerned SS7 destinations according to congestion procedures of EN 300 008-1 [3] and 
ITU-T Recommendation Q.704 [4]. The receiving node shall be able to detect local congestion and inform the 
transmitting node of this, by whatever means. 

Subsection 1.4.7 SCTP Stream Mapping 

SCTP stream mapping is implementation dependent, but any MSUs requiring sequenced delivery with respect to each 
other, shall be sent over the same stream. 

Subsection 1.4.8 Client/Server Model 

The SGP shall be able to support SCTP server operation and the ASP shall be able to support SCTP client operation. 
Support of both SCTP client and SCTP server operation at the ASP or SGP is optional. 

Subsection 3.4.1 Destination Unavailable (DUNA) 

The SG may suppress the sending of subsequent "response" DUNA messages regarding a certain unreachable SS7 
destination for T8 period to give the remote side time to react. See ITU-T Recommendation Q.704 [4] for T8. 

It is optional to send an affected point code parameter with more than one affected DPC in it, but the ability to receive 
this is mandatory. 

Subsection 3.4.3 Destination state Audit (DAUD) 

Destination state Audit (DAUD), shall be sent from ASP to SGP to audit the availability of SS7 routes from SG to one 
or more affected destinations. The frequency of the route test messages shall be as described for TIO. See ITU-T 
Recommendation Q.704 [4] for TIO. DAUD shall not be sent to audit the congestion or restricted state. 
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Subsection 3.4.4 Signalling Congestion 



The SCON message can be sent from an SGP to all concerned ASPs to indicate that a SG has determined that there is 
congestion in the SS7 network to one or more destinations. The receiving node shall be able to detect local congestion 
and inform the transmitting node of this, by whatever means. An SCON can be sent to ASP in response to DATA 
message, as appropriate. Multiple congestion levels are not supported. SCONs may be sent from the M3UA layer on 
ASP to M3UA peer indicating that the M3UA layer or ASP is congested. 

The sending of an SCON message shall not be delayed in order to collect a number of affected DPCs. Multiple affected 
DPCs may be included, as long as this does not delay the sending of the SCON message. 

Subsection 3.4.5 Destination User Part Unavailable (DUPU) 

The values here shall align with the MTP3 User Part Unavailable message and service indicator. Additional service 
indicator values may also be required. See EG 201 693 [5]. 

Subsection 3.4.6 Destination Restricted (DRST) 

Destination Restricted (DRST), shall not be sent. If DRST is received, it shall be discarded. 

Subsection 3.5.5 Heartbeat (BEAT) 

M3UA BEAT shall not be used. 

Subsection 3.5.6 Heartbeat Acknowledgement (BEAT Ack) 

M3UA shall return a BEAT ACK, if a BEAT is received. 

Subsection 3.8.1 Error 

An "unexpected message" error cause may be sent if a defined and recognized message is received that is not expected. 
The ASP may optionally discard the message and not send an error message. An "unsupported message class" error 
shall be sent if a message with an unexpected or unsupported Message Class is received. For a "destination status 
unknown error". Destination Unavailable (DUNA) shall be used. An error message is not required. 

Subsection 4.1.1 Receipt of Primitives from the M3UA-User 

The default treatment if no matching routing key entry is found for an incoming SS7 message is implementation 
dependent, but layer management shall be informed if the received message is discarded. 

Subsection 4.2.1 Receipt of M3UA Peer Management Messages 

ASPTM message may be sent on a stream used to carry data traffic related to the routing context. 

The BEAT ACK shall be sent. 

Subsection 4.3.4.1 ASP UP Procedures 

ASPTM messages shall only be sent after receipt of ASP-UP ACK. 

Subsection 4.3.4.3 ASP Active Procedures 

Once an ASP has received ASP-UP-ACK, it shall send ASP_Active message to SGP indicating ASP is ready to start 
processing traffic. The SGP shall only accept SS7 messages when ASP_Active is received. 

Multiple ASP_Active messages may be used to activate Application servers independently, or sets of Application 
servers, within SCTP limits. 

If SGP receives any data messages before ASP_Active message is received, it may discard them. M3UA Transfer and 
SSNM messages shall only be sent by an ASP after receipt of ASP-Active-Ack. 

Where an unexpected ASP_Active message is received the message may be silently discarded, as long as there is no 
disruption to traffic. 

If traffic handling mode of application server is not already known via configuration data, then the traffic handling 
mode in the received ASP active message shall be used to set the mode. 
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Subsection 4.3.4.4 ASP Inactive Procedures 



For loadshare mode AS, when ASP inactive results in "insufficient ASP resources active in AS", a notify message shall 
be sent to all inactive ASPs. 

Multiple ASP Inactive Ack messages may be used in response to an ASP Inactive message containing multiple routing 
contexts, within SCTP limits. 

Subsection 4.3.4.6 Heartbeat Procedures 

A heartbeat echo is mandatory, if M3UA heartbeat is received. 

Subsection 4.5.1 At an SGP 

DUPU and DAUD shall not be sent unsequenced. 

Subsection 4.5.3 ASP Auditing 

An ASP shall initiate an audit procedure to enquire of an SGP the availability of SS7 destination(s) every TIO s after a 
DPC becomes unavailable. It shall not initiate an audit procedure for congested or restricted status of SS7 destination(s). 
A DAUD shall not be sent unsequenced and shall be sent periodic (via TIO) or in case of isolation (ASP newly 
active/inactive). A DUNA or DAVA in response to a DAUD shall contain 1 or a list of affected point codes. The 
maximum number of affected DPCs that can be included shall be in line with the SCTP limits. A SG may discard the 
received request, or it may respond with a DUNA, if the ASP is not authorized to receive availability information of the 
concerned PC(s). 

Subsection 4.6 MTP3 Restart 

The ASP shall audit the availability of unavailable destinations by sending DAUD messages. 

Section 6 Security Considerations 

Security is out of scope of the present document. 

Section 7 lANA Considerations 

It is recommended that for server operation the IAN A registered port number for M3UA is set to 2905. SGPs may also 
use statically configured SCTP port numbers. The payload protocol ID (3), for M3UA, shall be used. If an 
unrecognizable payload protocol ID (i.e. neither nor 3) is received, the message shall be silently discarded. 
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